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Abstract

   This document updates the Cryptographic Algorithm Implementation
   Requirements for the Encapsulating Security Payload (ESP) and
   Authentication Header (AH).  It also adds usage guidance to help in
   the selection of these algorithms.

   ESP and AH protocols make use of various cryptographic algorithms to
   provide confidentiality and/or data origin authentication to
   protected data communications in the IP Security (IPsec)
   architecture.  To ensure interoperability between disparate
   implementations, the IPsec standard specifies a set of mandatory-to-
   implement algorithms.  This document specifies the current set of
   mandatory-to-implement algorithms for ESP and AH, specifies
   algorithms that should be implemented because they may be promoted to
   mandatory at some future time, and also recommends against the
   implementation of some obsolete algorithms.  Usage guidance is also
   provided to help the user of ESP and AH best achieve their security
   goals through appropriate choices of cryptographic algorithms.

   This document obsoletes RFC 4835.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7321.
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   This document is subject to BCP 78 and the IETF Trust's Legal
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   (http://trustee.ietf.org/license-info) in effect on the date of
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   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
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   material may not have granted the IETF Trust the right to allow
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   Without obtaining an adequate license from the person(s) controlling
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1.  Introduction

   The Encapsulating Security Payload (ESP) [RFC4303] and the
   Authentication Header (AH) [RFC4302] are the mechanisms for applying
   cryptographic protection to data being sent over an IPsec Security
   Association (SA) [RFC4301].

   To ensure interoperability between disparate implementations, it is
   necessary to specify a set of mandatory-to-implement algorithms.
   This ensures that there is at least one algorithm that all
   implementations will have in common.  This document specifies the
   current set of mandatory-to-implement algorithms for ESP and AH,
   specifies algorithms that should be implemented because they may be
   promoted to mandatory at some future time, and also recommends
   against the implementation of some obsolete algorithms.  Usage
   guidance is also provided to help the user of ESP and AH best achieve
   their security goals through appropriate choices of mechanisms.

   The nature of cryptography is that new algorithms surface
   continuously and existing algorithms are continuously attacked.  An
   algorithm believed to be strong today may be demonstrated to be weak
   tomorrow.  Given this, the choice of mandatory-to-implement algorithm
   should be conservative so as to minimize the likelihood of it being
   compromised quickly.  Thought should also be given to performance
   considerations, as many uses of IPsec will be in environments where
   performance is a concern.

   The ESP and AH mandatory-to-implement algorithm(s) may need to change
   over time to adapt to new developments in cryptography.  For this
   reason, the specification of the mandatory-to-implement algorithms is
   not included in the main IPsec, ESP, or AH specifications, but is
   instead placed in this document.  Ideally, the mandatory-to-implement
   algorithm of tomorrow should already be available in most
   implementations of IPsec by the time it is made mandatory.  To
   facilitate this, this document identifies such algorithms, as they
   are known today.  There is no guarantee that the algorithms that we
   predict will be mandatory in the future will actually be so.  All
   algorithms known today are subject to cryptographic attack and may be
   broken in the future.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].
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   We define some additional keywords here:

   MUST-  This term means the same as MUST.  However, we expect that at
      some point in the future this algorithm will no longer be a MUST.

   SHOULD+  This term means the same as SHOULD.  However, it is likely
      that an algorithm marked as SHOULD+ will be promoted at some
      future time to be a MUST.

2.  Implementation Requirements

   This section specifies the cryptographic algorithms that MUST be
   implemented, and provides guidance about ones that SHOULD or SHOULD
   NOT be implemented.

   In the following sections, all AES modes are for 128-bit AES. 192-bit
   and 256-bit AES MAY be supported for those modes, but the
   requirements here are for 128-bit AES.

2.1.  ESP Authenticated Encryption (Combined Mode Algorithms)

   ESP combined mode algorithms provide both confidentiality and
   authentication services; in cryptographic terms, these are
   authenticated encryption algorithms [RFC5116].  Authenticated
   encryption transforms are listed in the ESP encryption transforms
   IANA registry.

   Requirement    Authenticated Encryption Algorithm
   -----------    ----------------------------------
   SHOULD+        AES-GCM with a 16 octet ICV [RFC4106]
   MAY            AES-CCM [RFC4309]

2.2.  ESP Encryption Algorithms

   Requirement    Encryption Algorithm
   -----------    --------------------------
   MUST           NULL [RFC2410]
   MUST           AES-CBC [RFC3602]
   MAY            AES-CTR [RFC3686]
   MAY            TripleDES-CBC [RFC2451]
   MUST NOT       DES-CBC [RFC2405]
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2.3.  ESP Authentication Algorithms

   Requirement    Authentication Algorithm (notes)
   -----------    -----------------------------
   MUST           HMAC-SHA1-96 [RFC2404]
   SHOULD+        AES-GMAC with AES-128 [RFC4543]
   SHOULD         AES-XCBC-MAC-96 [RFC3566]
   MAY            NULL [RFC4303]

   Note that the requirement level for NULL authentication depends on
   the type of encryption used.  When using authenticated encryption
   from Section 2.1, the requirement for NULL encryption is the same as
   the requirement for the authenticated encryption itself.  When using
   the encryption from Section 2.2, the requirement for NULL encryption
   is truly "MAY"; see Section 3 for more detail.

2.4.  AH Authentication Algorithms

   The requirements for AH are the same as for ESP Authentication
   Algorithms, except that NULL authentication is inapplicable.

2.5.  Summary of Changes from RFC 4835

   The following is a summary of the changes from RFC 4835.

   Old            New
   Requirement    Requirement      Algorithm (notes)
   ----           -----------      -----------------
   MAY            SHOULD+          AES-GCM with a 16 octet ICV [RFC4106]
   MAY            SHOULD+          AES-GMAC with AES-128 [RFC4543]
   MUST-          MAY              TripleDES-CBC [RFC2451]
   SHOULD NOT     MUST NOT         DES-CBC [RFC2405]
   SHOULD+        SHOULD           AES-XCBC-MAC-96 [RFC3566]
   SHOULD         MAY              AES-CTR [RFC3686]

3.  Usage Guidance

   Since ESP and AH can be used in several different ways, this document
   provides guidance on the best way to utilize these mechanisms.

   ESP can provide confidentiality, data origin authentication, or the
   combination of both of those security services.  AH provides only
   data origin authentication.  Background information on those security
   services is available [RFC4949].  In the following, we shorten "data
   origin authentication" to "authentication".
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   Providing both confidentiality and authentication offers the best
   security.  If confidentiality is not needed, providing authentication
   can still be useful.  Confidentiality without authentication is not
   effective [DP07] and therefore SHOULD NOT be used.  We describe each
   of these cases in more detail below.

   To provide both confidentiality and authentication, an authenticated
   encryption transform from Section 2.1 SHOULD be used in ESP, in
   conjunction with NULL authentication.  Alternatively, an ESP
   encryption transform and ESP authentication transform MAY be used
   together.  It is NOT RECOMMENDED to use ESP with NULL authentication
   in conjunction with AH; some configurations of this combination of
   services have been shown to be insecure [PD10].

   To provide authentication without confidentiality, an authentication
   transform MUST be used in either ESP or AH.  The IPsec community
   generally prefers ESP with NULL encryption over AH.  AH is still
   required in some protocols and operational environments when there
   are security-sensitive options in the IP header, such as source
   routing headers; ESP inherently cannot protect those IP options.  It
   is not possible to provide effective confidentiality without
   authentication, because the lack of authentication undermines the
   trustworthiness of encryption [B96][V02].  Therefore, an encryption
   transform MUST NOT be used with a NULL authentication transform
   (unless the encryption transform is an authenticated encryption
   transform from Section 2.1).

   Triple-DES SHOULD NOT be used in any scenario in which multiple
   gigabytes of data will be encrypted with a single key.  As a 64-bit
   block cipher, it leaks information about plaintexts above that
   "birthday bound" [M13].  Triple-DES CBC is listed as a MAY implement
   for the sake of backwards compatibility, but its use is discouraged.

4.  Rationale

   This section explains the principles behind the implementation
   requirements described above.

   The algorithms listed as "MAY implement" are not meant to be endorsed
   over other non-standard alternatives.  All of the algorithms that
   appeared in [RFC4835] are included in this document, for the sake of
   continuity.  In some cases, these algorithms have moved from being
   "SHOULD implement" to "MAY implement".
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4.1.  Authenticated Encryption

   This document encourages the use of authenticated encryption
   algorithms because they can provide significant efficiency and
   throughput advantages, and the tight binding between authentication
   and encryption can be a security advantage [RFC5116].

   AES-GCM [RFC4106] brings significant performance benefits [KKGEGD],
   has been incorporated into IPsec recommendations [RFC6379], and has
   emerged as the preferred authenticated encryption method in IPsec and
   other standards.

4.2.  Encryption Transforms

   Since ESP encryption is optional, support for the "NULL" algorithm is
   required to maintain consistency with the way services are
   negotiated.  Note that while authentication and encryption can each
   be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10].

   AES Counter Mode (AES-CTR) is an efficient encryption method, but it
   provides no authentication capability.  The AES-GCM authenticated
   encryption method has all of the advantages of AES-CTR, while also
   providing authentication.  Thus, this document moves AES-CTR from a
   SHOULD to a MAY.

   The Triple Data Encryption Standard (TDES) is obsolete because of its
   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
   used to encrypt more than one gigabyte of data with a single key
   [M13].  Its key size is smaller than that of the Advanced Encryption
   Standard (AES), while at the same time its performance and efficiency
   are worse.  Thus, its use in new implementations is discouraged.

   The Data Encryption Standard (DES) is obsolete because of its small
   key size and small block size.  There have been publicly demonstrated
   and open-design special-purpose cracking hardware.  Therefore, its
   use is has been changed to MUST NOT in this document.

4.3.  Authentication Transforms

   AES-GMAC provides good security along with performance advantages,
   even over HMAC-MD5.  In addition, it uses the same internal
   components as AES-GCM and is easy to implement in a way that shares
   components with that authenticated encryption algorithm.

   The MD5 hash function has been found to not meet its goal of
   collision resistance; it is so weak that its use in digital
   signatures is highly discouraged [RFC6151].  There have been
   theoretical results against HMAC-MD5, but that message authentication
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   code does not seem to have a practical vulnerability.  Thus, it may
   not be urgent to remove HMAC-MD5 from the existing protocols.

   SHA-1 has been found to not meet its goal of collision resistance.
   However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is
   believed to be secure.

   HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to provide
   a good security margin, and they perform adequately on many
   platforms.  However, these algorithms are not recommended for
   implementation in this document, because HMAC-SHA-1 support is
   widespread and its security is good, AES-GMAC provides good security
   with better performance, and Authenticated Encryption algorithms do
   not need any authentication methods.

   AES-XCBC has not seen widespread deployment, despite being previously
   recommended as a SHOULD+ in RFC 4835.  Thus, this document lists it
   only as a SHOULD.

5.  Algorithm Diversity

   When the AES cipher was first adopted, it was decided to continue
   encouraging the implementation of Triple-DES, in order to provide
   algorithm diversity.  But the passage of time has eroded the
   viability of Triple-DES as an alternative to AES.  As it is a 64-bit
   block cipher, its security is inadequate at high data rates (see
   Section 4.2).  Its performance in software and Field-Programmable
   Gate Arrays (FPGAs) is considerably worse than that of AES.  Since it
   would not be possible to use Triple-DES as an alternative to AES in
   high data rate environments, or in environments where its performance
   could not keep up the requirements, the rationale of retaining
   Triple-DES to provide algorithm diversity is disappearing.  (Of
   course, this does not change the rationale of retaining Triple-DES in
   IPsec implementations for backwards compatibility.)

   Recent discussions in the IETF have started considering how to make
   the selection of a different cipher that could provide algorithm
   diversity in IPsec and other IETF standards.  That work is expected
   to take a long time and involve discussions among many participants
   and organizations.

   It is important to bear in mind that it is very unlikely that an
   exploitable flaw will be found in AES (e.g., a flaw that required
   less than a terabyte of known plaintext, when AES is used in a
   conventional mode of operation).  The only reason that algorithm
   diversity deserves any consideration is because there would be large
   problems if such a flaw were found.
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7.  Security Considerations

   The security of a system that uses cryptography depends on both the
   strength of the cryptographic algorithms chosen and the strength of
   the keys used with those algorithms.  The security also depends on
   the engineering and administration of the protocol used by the system
   to ensure that there are no non-cryptographic ways to bypass the
   security of the overall system.

   This document concerns itself with the selection of cryptographic
   algorithms for the use of ESP and AH, specifically with the selection
   of mandatory-to-implement algorithms.  The algorithms identified in
   this document as "MUST implement" or "SHOULD implement" are not known
   to be broken at the current time, and cryptographic research to date
   leads us to believe that they will likely remain secure into the
   foreseeable future.  However, this is not necessarily forever.
   Therefore, we expect that revisions of that document will be issued
   from time to time to reflect the current best practice in this area.
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